CM 
< 

CM 

U> 

o> 

00 



o. 

LU 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(43) Date of publication: 

25.07.2001 Bulletin 2001/30 

(21) Application number 01100685.5 

(22) Date of filing: 1 1 .01 .2001 



(H) EP1 118 952A2 

EUROPEAN PATENT APPLICATION 

(51) int CI 7: G06F 17/60, G06F9/44 



(84) Designated Contracting States: 


• Lange, Manfred 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


71131 Jettingen (DE) 


MC NLPTSETR 


• Trenz, Thomas 


Designated Extension States: 


72218 Gultllngen (DE) 


AL LT LV MK RO SI 






(74) Representative: 


(30) Priority: 11.01.2000 EP 00100505 


Lippich, Wolfgang, Dipl.-Pys., Dr.rer.nat. et al 




Patentanwalt Samson & Partner, 


(71 ) Applicant: Hewlett-Packard Company 


Widenmayerstrasse 5 


Palo Alto, California 94304-1112 (US) 


80538 MOnchen (DE) 


(72) Inventors: 




• Ulmer, Friedemann 




71131 Jettingen (DE) 





(54) System, method and computer program product for providing a remote support service 



(57) The invention is directed to a system for provid- 
ing a remote support service between at least one sup- 
port-service provider's site and a customer's site having 
a customer's information technological (IT) infrastruc- 
ture, comprising: an information collecting component 
which collects information about the customer's FT infra- 
structure; a storage component which stores collected 
information according to a data model modeling at least 



part of the customer's IT infrastructure; an information- 
transferring component capable of transferring at least 
part of the collected or stored information or a represen- 
tation of it to the support-service provider; and an anal- 
ysis component which analyzes the stored or trans- 
ferred information or representation as a basis for the 
provision of the remote support services. The invention 
is also directed to a corresponding method and compu- 
ter program product. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to in- 
formation technological (IT) infrastructure support, and 
more particularly to a system and a method for providing 
a remote support service between at least one support- 
service provider's site and a customer's site having a 
customer's IT infrastructure. The invention relates also 
to a computer system forming a customer based part of 
a system for providing a remote support service and a 
corresponding computer program product. 

BACKGROUND OF THE INVENTION 

[0002] For most companies the network (Internet or 
intranet) is the most critical and often the most compli- 
cated element of their entire IT infrastructure. Proprie- 
tary or customized networks therefore have to be main- 
tained by way of support services in order to maximize 
return on investment. These support services are deliv- 
ered by technical specialists, either locally or remotely. 
[0003] For support services to a local area network 
(LAN), there are network management systems availa- 
ble which provide detailed LAN health checks utilizing 
passive monitoring probes. Full analysis and any errors 
or capacity problems identified are documented in a re- 
port. They further provide remote LAN monitoring by a 
remote log-in via a network or an ISDN connection. 
Monthly reports can detail utilization errors and protocol 
use. A recommendation on solutions to any problems 
identified may be included in the report. In addition, the 
service can include alarm recording and problem diag- 
nosis. 

[0004] The present applicant offers an enterprise-ori- 
ented Network Node Manager (Open View™) which has 
a Web interface. In particular, a Web browser is shipped 
together with the Open View™ Professional Suite, which 
is a comprehensive software solution that allows cus- 
tomers in small to midsize networked environments to 
manage virtually all elements of a LAN. Thus the Open- 
View™ Professional Suite combines the power of a cen- 
tral management console with the ease of using the 
Web for communication. 

[0005] Network management of a TCP/IP network 
comprises network management stations (managers) 
communicating with network elements. The network el- 
ements can be anything that runs the TCP/IP protocol 
suite: hosts, routers, terminal servers, etc. (Regarding 
the meaning of the term TCP/IP protocol suite", see W. 
Richard Stevens: TCP/IP Illustrated, Volume 1 , The Pro- 
tocols, 1994, pages 1-2). The protocol for the commu- 
nication between the manager and the elements provid- 
ed by the TCP/IP protocol suite is the Simple Network 
Management Protocol (SNMP). It allows a two-way 
communication: a manager can ask an element for a 
specific value, or the element can tell the manager that 



something happened. Also, the manager is able to set 
variables in the element, in addition to reading variables 
from it. A description of SNMP can, for example, be 
found in Stevens, pages 359-388. 

5 [0006] Another standard for network management is 
what is called Desktop Management Interface (DM I). It 
has been defined by the Distributed Management Task 
Force (DMTF). DM I is a standard framework for man- 
aging and tracking components in a desktop personal 

10 computer, notebook or server (see http://www.dmtf. org/ 
spec/dmis.html). 

[0007] An emerging standard for the management of 
operating systems and applications is the Web-Based 
Enterprise Management (WBEM). WBEM is a set of 
is management tools using emerging technologies such 
as CIM and XML. In particular, WBEM is a set of the 
following technologies: "CIM Schema v 2.2", "CIM op- 
erations over HTTP", and "XML encodings for CIM" (see 
http^/www.dmtf.orpywbem/index.html). CIM stands for 
20 Common Information Model and is a data model for de- 
scribing information for the management of enterprise 
computing environments. XML stands for Extensible 
Markup Language and is a standard which can be used 
for exchanging massages between different applica- 
25 tions (see http://www.w3.org/tr/rec-xml). 

SUMMARY OF THE INVENTION 

[0008] A system for providing a remote support serv- 

30 ice between at least one support-service provider's site 
and a customer's site having a customer's IT infrastruc- 
ture, comprises: an information collecting component 
which collects information about the customer's IT infra- 
structure; a storage component which stores collected 

35 information according to a data model modeling at least 
part of the customer's IT infrastructure; an information- 
transferring component capable of transferring at least 
part of the collected or stored information or a represen- 
tation of it to the support-service provider; and an anal- 

40 ysis component which analyzes the stored or trans- 
ferred information or representation as a basis for the 
provision of the remote support services. 
[0009] According to another aspect, the invention pro- 
vides a computersystem forming a customer based part 

45 of a system for providing a remote support service be- 
tween at least one support-service provider's site and 
the customer's site having a customer's IT infrastruc- 
ture. The computer system comprises: an information 
collecting component which collects information about 

so the customer's IT infrastructure; a storage component 
which stores collected information according to a data 
model modeling at least part of the customer's IT infra- 
structure; and an information-transferring component 
capable of transferring at least part of the collected or 

55 stored information or of a consolidated representation 
of it to the support-service provider. 
[001 0] According io stiii another aspect, the invention 
is directed to a computer program product including pro- 
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gram code for execution on a customer-based computer 
system which is part of a system for providing a remote 
support service between at least one support-service 
provider's site and the customer's site having a custom- 
er's IT infrastructure. The program code comprises the 
software parts of: an information collecting component 
which collects information about the customer's IT infra- 
structure; a storage component which stores collected 
information according to a data model modeling at least 
part of the customer's IT infrastructure; an information- 
transferring component capable of transferring at least 
part of the collected or stored information or of a con- 
solidated representation of it to the support-service pro- 
vider. 

[0011] According to yet another aspect, the invention 
is directed to a method for providing a remote support 
service between at least one support-service provider's 
site and a customer's site having a customer's ff infra- 
structure. The method comprises the steps of: collecting 
information about the customer's IT infrastructure; stor- 
ing collected information according to a data model 
modeling at least part of the customer's IT inf rastructu re; 
transferring at least part of the collected or stored infor- 
mation or a representation of it to the support-service 
provider; and analyzing the stored or transferred infor- 
mation or representation as a basis for the provision of 
the remote support services. 

[0012] Other features are inherent in the disclosed 
system, computer program product and method or will 
become apparent to those skilled in the art from the fol- 
lowing detailed description of embodiments and its ac- 
companying drawings. 

DESCRIPTION OF THE DRAWINGS 

[0013] In the accompanying drawings: 

Fig. 1 shows an architectural overview of a pre- 

ferred embodiment; 

Fig. 2 shows an architectural representation of 

parts of an infrastructure documentation 
tool of Fig. 1 ; 

Fig. 3 shows a more detailed functional archi- 

tecture of a data collector ; 

Fig. 4 shows a more detailed functional archi- 

tecture of a collection configuration com- 
ponent; 

Fig. 5 shows a more detailed functional archi- 

tecture of a transport office manager; 

Fig. 6 illustrates a distributed application stack 

of a customer's IT infrastructure; 

Fig. 7 shows a graphical representation of an 

instance of a data model modeling a cus- 
tomer's IT infrastructure; 

Fig. 8 illustrates a data model of a network 

node; 

Fig. 9 illustrates a data mode! of a computer 

system; 
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Fig. 1 0 illustrates a data model of a storage sys- 

tem; 

Fig. 11 illustrates the inheritance of the data 

models of Figs. 8 to 10 from more gen- 
eral classes; 

Fig. 1 2 illustrates how an element of the IT infra- 

structure is mapped to a class with dy- 
namic attributes; 
Fig. 1 3 is a table illustrating the concept of meta 

classes for achieving dynamic extensi- 
bility of the data modeli- 
ng. 14 shows a flow diagram of a remote sup- 
port-service method; 
Fig. 15 illustrates an embodiment wherein the 
support service is provided by several 
co-operating sub-services; 
Fig. 1 6 illustrates a collection task; 
Fig. 1 7 illustrates a scheduling task; 
Fig. 18 shows collectible interfaces; 
20 Fig. 1 9a-c show further interfaces; and 
Fig. 20 illustrates a DM I collection task. 



DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0014] Features that are substantially or functionally 
equal or similar will be referred to with the same refer- 
ence sign(s). 

[0015] Figure 1 shows an architectural overview of a 
preferred embodiment. Before proceeding further with 
the description, however, a few items of the preferred 
embodiments will be discussed. 
[0016] The preferred embodiments of the system al- 
low for an automatic capture of configuration and per- 
formance information of the customer's IT infrastructure 
via a data collection mechanism which is independent 
of hardware devices. The process runs as a background 
task. The collected information is stored in a storage 
component according to a data model which models at 
least part of the entire IT infrastructure which includes, 
but is not limited to network interconnect hardware and 
related software. Preferably, the data model models the 
whole infrastructure. Based on that data model, an anal- 
ysis component, located at the service provider's site 
and/or the customer's site analyzes the collected or 
stored information or a representation of it. 
[0017] In the preferred embodiments, a storage com- 
ponent is located at the customer's site since access to 
the customer's site from outside is normally restricted or 
excluded dueto security requirements. In addition, there 
is another storage component located at the provider's 
site. In other embodiments, the storage component stor- 
ing collected data according to the data model is only 
located at one of the sites, either the support-service 
provider's site or the customer's site. 
[0018] In the preferred embodiments, the analysis 
component is located at the support-service provider's 
site; i.e. the stored data or an extract of them are trans- 
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mitted to the support-service provider's site and are an- 
alyzed there. The analysis can be individually tailored 
to the customer, depending on the particular support 
contract between customer and provider. The support- 
service provider receives data from the customer, pref- 
erably via the Internet using e-mail, HTTP or a point-to- 
point Internet connection, performs the diagnosis and 
sends a report or message back to the customer, again 
via the Internet for example by sending XML. However, 
it is likewise possible that the analysis component is lo- 
cated at the customer's site and the analysis is being 
done there. Then, the results of the analysis are trans- 
ferred to the service provider's site, where the support- 
service server can, for example, automatically arrange 
for service personnel to be sent to the customer, if the 
result indicates a fault condition. Further, it is possible 
that a customer is linked to several co-operating sup- 
port-service providers and transfers data to them. For 
example, each provider could be responsible only for 
certain IT infrastructure elements (for example, for cer- 
tain hardware devices). There could also be a hierarchi- 
cal structure of support-service providers in the sense 
that there are several sub-providers (responsible only 
for providing support for certain parts of the IT infrastruc- 
ture) and one master provider (responsible for providing 
an overall support). 

[0019] If the bandwidth of the network link(s) between 
the customer and the service providers) is limited, it 
may be advantageous to consolidate the data before 
they are transferred to the provider. If bandwidth limita- 
tions are not relevant, a consolidation can likewise be 
performed at the provider. It is also possible to perform 
consolidation actions at both sites. Consolidating 
means compressing data, e.g. by filtering or condensing 
them or by detecting certain events. 
[0020] The customer's IT infrastructure that can be 
discovered, monitored and analyzed by the disclosed 
embodiments is not restricted to hardware. Rather, it 
may comprise one or more of the following elements: 
network infrastructure elements, storage systems, hard- 
ware elements and peripherals, operating systems, net- 
working software, database software, middleware and 
utilities, software applications. The information collect- 
ing component collects information about at least one 
of these elements and the data model models at least 
part of these elements and their inter-relations. 
[0021 ] The preferred embodiments of the system fu r- 
ther comprise a discovery component which is capable 
of automatically discovering changes in the customer's 
IT infrastructure. There are many sources of ongoing 
changes in an IT infrastructure, for example: Failure of 
infrastructure elements, fixing of failed infrastructure el- 
ements, extensions and enhancements of the infra- 
structure, user process changes, application changes, 
interface changes, installation or activation of new ap- 
plications and software modules, version upgrades, in- 
clusion of new organization units, etc. The data mode! 
is automatically adapted so that it models the changed 



IT infrastructure. Owing to the automatic discovering ca- 
pability of the discovery component, after an installation 
of a program code representing the software part of the 
system at the customer's site, the system can automat- 

5 ically discover at least part of the customer's IT infra- 
structure and automatically and dynamically generate 
and stores data which represent it. 
[0022] In order to allow this dynamic generation and 
modification in the preferred embodiments, the ele- 

10 ments of the customer's IT infrastructure are mapped to 
classes of an object-oriented programming language (i. 
e., they become instances of those classes), and new 
classes (instances) can dynamically be added. The 
classes have flexible attributes which can dynamically 

is be added and changed during the execution of the pro- 
gram. This is advantageous for the system's capability 
to automatically adapt itself to changes in the IT infra- 
structure. 

[0023] In a preferred embodiment, the information- 
20 transferring component comprises transport managing 
means whereby the collected configuration information 
is transferred via an information network, particularly the 
Internet, or by means of a data carrier. An IT infrastruc- 
ture support service can therefore be handled as an 
25 electronic service as part of electronic commerce and 
business. The proposed web-based approach facili- 
tates the provision compatibility, platform-independ- 
ence and high accessibility. 

[0024] As already mentioned above, a scaleable stor- 

30 age component, in particular an object-oriented data- 
base is provided. Using a scaleable database allows an 
unlimited growth of the IT infrastructure. 
[0025] The storage component may be capable of 
storing performance history information for the IT inf ra- 

35 structure. This facilitates the monitoring and/or analyz- 
ing of the IT infrastructure and the assessment whether 
the infrastructure performance can be enhanced 
through updates of the infrastructure hardware and soft- 
ware. Further, history information allows improved diag- 

40 nosis and performance checks. The configuration, con- 
figuration changes, performance and/or performance 
changes of the customer's rT infrastructure are automat- 
ically monitored and analyzed particularly based on 
rules. Such rules define what checks and configuration 

45 test are to be performed are to be performed in an in- 
frastructure element of a particular type. The rule are 
not "hard coded". Rather they can be input as ASCII 
strings and are interpreted (similar to a script language 
such as Visual Basic Script). Additionally it is possible 

so with the preferred embodiments to monitor infrastruc- 
ture health, including but not limited to, trend analysis, 
forecasts, traffic assessment and problem prediction. 
[0026] In the preferred embodiments, a scheduler for 
scheduling the collection of the infrastructure informa- 

55 tion is provided. The scheduler determines when a col- 
lection task is be carried out. 

[0027] The preferred embodiments of the computer 
program product comprise program code which, for ex- 
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ample, is stored on a computer-readable data carrier or 
is in the form of signals transmitted over a computer net- 
work. The preferred embodiments of the program code 
are written in an object-oriented programming language 
(Java or C+ +). Some of the mentioned components 
have also a hardware part. For example, the storage 
component comprises a physical storage medium for 
persistently storing the collected data. It is clear that the 
computer program product comprises only the software 
parts of these components. 

[0028] Returning now to Fig. 1 , it shows an architec- 
tural overview of preferred embodiment of a computer 
system for providing a remote support service. The sys- 
tem is subdivided into an Infrastructure Documentation 
Tool (IDT) 1 at the customer's site and an Infrastructure 
Support Service Tool (ISST) 2 on the support-service 
provider's site. The two sites are linked via a network, 
for example an IP link using HTTP 3, e-mail 4 or a point- 
to-point Internet connection (not illustrated). 
[0029] The customer's IT infrastructure generally 
comprises network infrastructure elements (such as 
routers and switches), storage systems, hardware ele- 
ments (such as desktop computers), peripherals (such 
as printers and scanners). Further, it generally compris- 
es software elements, such as operating systems, net- 
working software, database software, middleware, util- 
ities and software applications. In Fig. 1 , the customer's 
IT infrastructure 5 is visualized as a tree-like structure, 
but, more generally, it can be a graph-like structure. 
[0030] The several functional elements of the IDT 1 
are controlled by an IDT controller 6,. which is the heart 
of the IDT 1 . It controls a discovery component 7 which 
runs automatically and periodically as a background 
task, for example once per day (a component with such 
a function is also called a "demon"). The discovery com- 
ponent is capable of discovering an appearance, disap- 
pearance or a change in infrastructure elements, such 
as routers, switches, hosts, software applications etc. 
The discovery component 7 sends requests to (yet un- 
known) infrastructure elements by using what is called 
the Ping application (see Stevens, pages 85 to 96). In 
order to discover unknown infrastructure elements it 
sends many trial requests with different possible IP ad- 
dresses, which possibly do not exist in the infrastructure 
5. If, by chance, it uses the IP address of the (yet un- 
known) infrastructure element, this element will respond 
and disclose its identity in the response. The discovery 
component 7 uses a network management protocol, 
such as SNMP, to discover network elements, such as 
routers. In order to discover software elements, it uses 
a suitable protocol, such as WBEM. 
[0031 ] Ping may not be the optimal solution , if the sub- 
net contains many devices, e.g. when the subnet mask 
is big, e.g. 255.255.0.0. In this case reading the ARP 
cache (see Stevens, pages 53 to 64, in particular page 
56) is preferred. An ARP cache contains the resolved 
network addresses of other devices with which a recent 
communication across the network took place. Best 



candidates for reading ARP caches are therefore gate- 
ways or servers. 

[0032] The discovery components 7 starts the discov- 
ery task "within itself, i. e. on the IDT server computer 
5 on which it runs, and first discovers the gateway to the 
infrastructure 5. Then, it discovers the first node in the 
infrastructure 5 and receives the requested identity in- 
formation from it, by means of the above-described 
method. Then, this node constitutes the starting point 
10 for the discovery of the adjacent nodes. If the node is a 
switch, it provides the discovery component 7 with in- 
formation as to which device is linked to which port of 
the switch. If the infrastructure element is a router, the 
above-described discovery method can be simplified as 
routers commonly store a list of used IP addresses in 
their cache. If the discovery component 7 can acquire 
such a stored list of used IP addresses, it can use them 
for the further discovery task rather than trying a large 
number of arbitrary IP addresses. 
[0033] By this method, the discovery component 7 not 
onfy discovers the elements of the infrastructure 5, but 
also their inter-relations, which define the topology of 
the infrastructure 5. In Fig. 1 the topology is illustrated 
as a tree-like structure. 

[0034] The discovered infrastructure elements and 
the infrastructure topology are mapped to objects of an 
object-oriented data model. The objects are persistently 
stored in an object-oriented database, which forms part 
of a storage component 8. The schema of the data base 
(i.e. the data model) can be dynamically modified. Thus, 
if the discovery component 7 discovers a modification 
of the infrastructure 5 (e.g. the appearance, disappear- 
ance or a change of attributes of an infrastructure ele- 
ment), it is not necessary to create a new database 
schema. Rather, the database schema already used by 
the storage component 8 is modified correspondingly, 
e.g. by dynamically adding or removing an object or 
changing an objects attributes list. 
[0035] A data collector 9 collects information about 
the infrastructure 5 on the basts of the discovered ele- 
ments and the discovered infrastructure topology. The 
collected information is mainly configuration and per- 
formance information. The collected data are stored in 
the storage component 8 according to the data model. 
[0036] An information-transferring component 10a, 
here denoted as transport office manager, transfers da- 
ta collected by the data collector 9 and stored in the stor- 
age component B to the ISST 2 via the HTTP link 3 or 
the e-mail link 4. 

[0037] The data collector 9 is configured by a collec- 
tion configuration component 11 . A core service compo- 
nent 12 allows the configuration and debugging of the 
IDT 1 . A web server 13 permits an HTTP access to the 
IDT 2, for example by an infrastructure administrator or 
configurator or the support-service provider. 
[0038] The ISST 2 at the support-service provider's 
site comprises a transport office manager 1 0b which is 
the counterpart of the IDT's transport office manager 
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10a. It receives the infrastructure collection and topolo- 
gy data sent by the transport office manager 1 0a. These 
data are stored in an ISST storage component 14 via 
an import service component 1 5. Also in the ISST stor- 
age component 14, the data are stored according to the 
data model. 

[0039] An analysis component 1 6 analyses the topol- 
ogy and collected data with regard to the particular sup- 
port service to be provided to the customer. For exam- 
ple, the analysis component 16 can provide an infra- 
structure map (i.e. a graphical representation of the in- 
frastructure as illustrated at 5). The collected informa- 
tion may include not only the network configuration, but 
also software configuration information, such as the ver- 
sion number as well as patch and bug-fix information of 
installed software (e.g. operating systems, middleware 
and applications). Thus, the analysis component 1 6 can 
monitor the software configuration status. It can also an- 
alyze the collected data regarding the performance and 
hearth of the infrastructure, and include these results in 
the graphical infrastructure representation. Personnel 
from the customer's or the support-service provider's 
site can access these results via an ISST web server 1 7 
(which includes a web manager) and an access service 
component 1 8. The analysis component 1 6 can also act 
as an "alarm system" which detects imminent or already 
existing faults or malfunctions of the infrastructure 5 and 
notifies the customer correspondingly via the web serv- 
er 17. Depending on the particular support service to be 
provided, the analysis component may also initiate the 
steps which are necessary to remedy or avoid the fault 
or malfunction, for example by sending corresponding 
instructions to the customer's network administrator via 
the web server 1 7 or by arranging for corresponding 
measures to be taken by external service personnel. 
[0040] A further web server 1 9 is provided at the ISST 
2 which allows HTTP access for controlling and config- 
uring the ISST 2. 

[0041] In the preferred embodiment shown in Fig. 1 , 
the topology data as well as the collected data are stored 
at the customer's site, since commonly IP access to the 
customer's infrastructure 5 from outside is restricted by 
a firewall (not shown). However, in other embodiments 
(not shown) the discovery and collection data are sent 
to the ISST 2 without being stored according to the data 
model at the customer's site. In a further embodiment 
(not shown) only the information concerning the topolo- 
gy is stored at the customer's site in order to allow a data 
collection with reduced external access, but the collect- 
ed information is sent to the ISST 2 without being stored 
at the customer's site. 

[0042] In contrast to the above, it is likewise possible 
to shift more "responsibility" from the support-service 
provider's site to the customer's site. In particular, if the 
bandwidth of the link 3, 4 between the IDT 1 and the 
ISST 2 is limited, it is advantageous to reduce the 
amount of data to be transferred via this link. Therefore, 
in a further embodiment a data consolidator 20 (shown 



with dashed lines in Fig. 1 ) consolidates (e.g. filters) the 
collected data. Then, only the consolidated data are 
sent to the ISST 2. In still further embodiments, the ISD 
1 comprises an analysis component (not shown), which 
5 already performs the entire topology and collection data 
analysis or a part of it at the customer's site. Only data 
which represent the results of the analysis are then sent 
to the support-service provider. The transferred data 
may represent a fault message or an alarm which in- 
to forms the ISST 2 that measures to remedy or avoid the 
fault situation have to be taken. 
[0043] Fig. 2 shows a more detailed architectural rep- 
resentation of a part of the IDT 1 of Fig. 1 . The data 
collector 9 collects configuration and performance infor- 
ms mation of the IT infrastructure 5 for example data con- 
cerning network interconnecting devices (such as rout- 
ers, switches) and software components (such as oper- 
ating systems, middleware and applications). The data 
collector 9 comprises a collection scheduler 21 and sev- 
20 eral sub-collectors for the different collection protocols: 
a DMI collector 22 and a SNMP collector 23 collect in- 
formation about network devices, such as routers, 
switches and hosts. A configuration file collector 24 col- 
lects data from configuration files of devices. A WBEM 
25 collector 25 collects information about software compo- 
nents. 

[0044] The data collector 9 provides for the following 
functional options: 

30 • Collection on demand (immediate and synchro- 
nous, collection); 
• Collection according to a schedule on a regular (e. 
g. periodic) basis. 

35 Particularly, it can run as a background task. 

[0045] Interfaces provided by the collection configu- 
ration component 11 which can be accessed e.g. by a 
user or infrastructure support manager via the Web 
server 13 (Fig. 1 ) are, 

AO 

1 . as part of the specification of collection tasks: 

• the definition of what shall be collected (defini- 
tion of a "collectable"); 

45 • which device identification shall be used; 

• specification of schedules per collectible; 

• how or where to deliver the result; 

2. the initiation of a data-collection procedure (if the 
50 collection is to be earned out on demand). 

[0046] The following figures 3, 4 and 5 show the col- 
lector component 9 the collection configuration compo- 
nent 11 , and the transport office manager 10a together 
55 with the IDT controllers, in more detail. This is illustrated 
in Fig. 2 with dashed circles around the corresponding 
elements. 

[0047] Fig. 3 shows a more detailed functional archi- 
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tecturc of the data collector 9. The small circles depicted 
on the right-hand side of the small boxes indicate soft- 
ware interfaces. The data collector 9 splits into three lay- 
ers 31 , 32, 33. The first layer, the protocol layer 31 , does 
the actual collection work. The components of this layer, 
the DMI collector 22, the SN MP collector 23, the config- 
uration file collector 24 and the WBEM collector 24, use 
particular protocols (DMI, SNMP, WBEM) and access 
methods (e.g. SNMP combined with TFTP) to collect in- 
formation from infrastructure elements. The second lay- 
er, the strategies layer 32, contains different collection 
strategies, for example a sequential collection strategy 
34 and a parallel collection strategy 35. Sometimes it is 
preferable to use a mixed strategy rather than the pure 
parallel strategy in order not to bother the infrastructure 
elements with too many requests at a time. For example, 
with SNMP a restricted parallel strategy can be used 
which prevents the collector from sending two SNMP 
requests at the same time to a particular element. How- 
ever, two or more requests can be sent to different de- 
vices in parallel. The corresponding strategy is denoted 
with 36 in Fig. 3. 

[0048] The third layer, the basic services Iayer33 pro- 
vides the basic functionality of how to define a collection 
task. A collection scheduler37 defines when acollection 
has to take place. For example, a collection queue could 
determine that a collection has to be carried out every 
full hour. A collectible schedule component 38 defines 
what data have to be collected. A TFTP module 39 pro- 
vides means to retrieve data via TFTP. 
[0049] Before any data can be collected, the following 
definitions of the collection task have to be made: 

what to collect (with a collectible definition), 
- when to collect (with a schedule), 

from which infrastructure element to collect (with el- 
ement information), 

whom to notify when the collection is complete (with 
a notification object), 

where to deliverthe result (with a result object), and 
who defined the task (with an identifier). 

[0050] The dynamic behavior of the scheduler 9 is il- 
lustrated in Fig. 3 by reference signs S1 to S9. In the 
first steps S1 and S2 the IDT controller 6 defines the 
following items of the collection task: From which device 
to collect (IP address of the device), what to collect (def- 
inition of collectible) and where to deliverthe result (step 
S1) as well as when to collect (schedule) (step S2). In 
the next step S3 the IDT controller 6 forwards the col- 
lection task to the collector on the protocol layer (here 
the SNMP collector 23). Then in step, S4, the SNMP 
collector 23 configures the collection scheduler 37 with 
the collection task. After step S4 the work is done for the 
collector 23. In step S5 the collection scheduler 37 fetch- 
es the collection schedule from the collectible schedule 
component 3ft The -scheduler 37 holds a list of a!! 
scheduled collection tasks. If the task is ready for col- 



lection (for example, when the point of time when the 
collection shall be started has been reached) it passes 
the collection task in step S6 to the strategy layer 32, in 
the example shown in Fig. 3 to the strategy 36 ("different 

5 elements in parallel"). The strategy 36 coordinates the 
access to the infrastructure elements and initiates the 
actual collection (step S7). In step S7the protocol layer 
(here the SNMP protocol 23) retrieves the data about 
the infrastructure and returns the result in step S8 to the 

10 IDT controller 6. 

[0051] Fig. 4 shows a detailed functional architecture 
of the collection configuration component 11 of Fig. 2. 
The collection configuration component 11 provides in- 
formation as to what data shall be collected for a given 

« infrastructure element, what is called a "collectible". The 
infrastructure elements are denoted as "devices" in Fig. 
4. Collectible data may be from configuration files, log 
files, interface tables, routing tables, health parameters, 
version, patch and update description data, usage, load 

20 and performance data etc. The collectible definitions are 
contained in collectible definition files, here an SNMP 
collectible definition file 43, a DMI collectible definition 
file 44, a WBEM collectible definition file (not shown) etc. 
Device classes are listed in a device-classes file 41 . A 

25 relation file 42 contains relations between device class- 
es and collectibles. A collection configuration element 
45 can retrieve a collectible definition for a given device 
and a given collection protocol by first accessing the de- 
vice classes and relation files 41 and 42 in order to find 

30 out the correct collectible for the given device, and then 
the SNMP collectible definition file 43 via a SNMP con- 
figuration reader 46 (or the DMI collectible definition file 
44 via a DMI configuration reader 47, etc.). The files 41 
to 44 are, for example, parsed with TCL (Tool Control 

35 Language). 

[0052] The sequence of a collection configuration 
task is indicated by reference signs T1 and T2 in Fig. 4: 
In step T1 , the IDT controller 6 requests a collectible for 
a given device from the collection configuration compo- 

40 nent 11. The collection configuration element 45 re- 
trieves the collectible in the above-described manner 
and returns it to the IDT controller 6. In step T2, the IDT 
controller 6 forwards the configuration task to a protocol 
specific collector, here an SNMP data collector 48. 

45 [0053] Fig. 5 shows a detailed functional architecture 
of the transport office manager 1 0a, which is implement- 
ed in the customer's IDT 1 . A corresponding transport 
office manager is implemented at the provider's ISST2, 
which is indicated by 1 0b in Fig. 5. The transport office 

so managers 1 0a, 1 0b are operating-system independent. 
It is thus possible to use different operating systems on 
both sides, for example Windows NT on the one side 
and UNIX on the other side. The transport office man- 
agers 1 0a, 1 0b are implemented independently of the 

55 transmission protocol and thus can be used for, e.g., HT- 
TP transmission or e-mail transmission. The transport 
office managers 10a, 10b have two functional parts, a 
send part and a receive part. Each transport office man- 
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ager 1 0a, 1 0b comprises a transport office manager el- 
ement 51 , which controls the overall function, and a 
send module 52 and a receive module 53, which are 
responsible for sending and receiving data. The sending 
of data from the IDT 1 to the ISST 2 is performed ac- 
cording to the following sequence: In step 111 , a file to 
be sent is provided by the IDT controller 6. In step U2, . 
the IDT controller 6 notifies the transport office manager 
1 0a that the file has to be sent, the manager 1 0a passes 
the notification to the send module 52. The send module 
52 fetches the file and forwards it to an e-mail sender 
54 or a HTTP sender 55 which performs the dispatch of 
the file. 

[0054] The receipt of data from the infrastructure sup- 
port-service tool 2 at the infrastructure documentation 
tool 1 is performed according to the following sequence: 
In step U3, the IDT controller 6 registers a call-back in- 
terface (depicted by a small circle at step U4). In step 
U4, the transport office manager element 51 invokes the 
registered interface. Then, in step U5 the receive mod- 
ule 53 fetches the received file from an e-mail receiver 
56 or an HTTP receiver 57 and forwards itrto the IDT 
controller 6 (or the ISST storage device, if the file is re- 
ceived at the support-service provider's site). 
[0055] Fig. 6 illustrates a hierarchy of different cus- 
tomer infrastructure elements that can be subjected to 
the disclosed discovery and monitoring process. The hi- 
erarchy of these elements forms what is called the dis- 
tributed application stack of the customer's IT infrastruc- 
ture 5. It comprises the following elements in hierarchi- 
cal order: network infrastructure (such as routers and 
switches), storage system, hardware (such as desktop 
computers and peripherals (such as printers), operating 
systems, networking software, database software, mid- 
dleware and utilities, software applications. 
[0056] The IT infrastructure 5 including these ele- 
ments is mapped to a customer's environment model, 
which also called a "data model", and is stored in the 
IDT storage component 8 and/or the ISST storage com- 
ponent 14. An example of a graphical representation of 
an instance of the data model is shown in Fig. 7. The 
data model is object-oriented and uses an object-orient- 
ed database. An object of the data model corresponds 
to each infrastructure element. Relations between infra- 
structure elements (i. e. the topology of the infrastruc- 
ture) are mapped to corresponding relations between 
the objects, and features of the infrastructure elements 
which are relevant for the disclosed monitoring process 
are modeled by ciass attributes in the data model. The 
instance shown in Fig. 7 has a tree structure. Depending 
on the actual IT infrastructures, other topologies, such 
as graphs, can be modeled. 

[0057] Examples of detailed data models of individual 
elements of an IT infrastructure are shown in Figs. 8 to 
10: Fig. 8 illustrates the data model of an element of the 
lowest layer in the application stack, a network node 
(here: a rouier 71). A network node is a hardware ele- 
ment which is link to a network, such as a server, a work- 



station, a printer, a router, a switcher, a gateway, other 
interconnect devices, etc. Fig. 9 illustrates the data mod- 
el of another network node, a computer system 72. Fig. 
10 illustrates the data model of a storage system 73. 

s The corresponding classes are named "NetworkNode", 
"ComputerSystem" and "StorageSystem". The relation 
of "StorageSystem" to "ComputerSystem" of Fig. 9 is 
included in classes "PhysicaiDisk" and "DiskController". 
A data model of a software application (not shown) can , 

10 for example, include the installed version of the software 
application, patches, updates, to the status of the appli- 
cation, its performance, etc. 

[0058] Fig. 1 1 illustrates that the classes shown in Fig. 
8 to 1 0 are inherited from other, more general classes. 

15 in particular, as indicated by open arrows, "Computer- 
System" and "StorageSystem" are generalized in to 
class "System", and "NetworkNode" is generalized to a 
class "NodeElmt". In turn, these two classes are gener- 
alized to a class "ExtensibleObject". 

20 [0059] The mapping of the elements of the IT infra- 
structure 5 to classes is dynamical, which is illustrated 
in Fig. 12. As most of the classes in the database sche- 
ma (that is the data model) are derived from Extensible- 
Object 62, which in turn is derived from PersistentObject 

25 61 , these classes can be dynamically extended at runt- 
ime by creating and associating instances of any of the 
subclasses of Property 63. In particular the preferred 
embodiment provides for ScalarProperty 64, Array Prop- 
erty 66 and Group Property 65. Each ScalarProperty ob- 

30 ject can store all kinds of scalar values, such as integers 
with varying precision, floating point numbers with var- 
ying precision, strings of virtually arbitrary length or bi- 
nary data of virtually arbitrary length. Alternatively a 
ScalarProperty object can also contain a reference to a 

35 different object in the same or a different database. This 
mechanism is also used to dynamically store associa- 
tions between objects in the database. An ArrayProper- 
ty object consists of ScalarProperties objects, which can 
be accessed using an index. An ArrayProperty is dy- 

40 namic not only in the size, but also in the number of di- 
mensions it has. For example, in the one dimensional 
case it represents a vector, in the two dimension case it 
is a table. A GroupProperty object provides for grouping 
other Property objects. This means can be used for 

45 grouping Properties, for example, information related to 
a particular network protocol, e.g. UDP, can be put into 
a single GroupProperty. The information on a different 
protocol, e.g. TCP can then be put in a second group. 
As GroupProperty is derived from Property, and as a 

so GroupProperty object groups other Property objects, 
this also means that a GroupProperty object can contain 
other GroupProperty objects. In other words, Group- 
Property objects can be nested. 
[0060] The dynamic extensibility of the databases 

55 schema is achieved by the use of meta classes. Such 
meta classes have attributes which are classes. This is 
illustrated in the table of Fig. 13: The left-hand column 
shows the logical level. The lowest level is the Object 



8 



EP1 118 952 A2 



16 



15 

level, the medium level is the Class level, and the high- 
est level is the Meta level. Commonly, only the Object 
level and the Class level are used in object-oriented pro- 
gramming. The column in the middle indicates the name 
of the "concept" used in these levels, namely "Object", 
"Class" and "MetaClass". The right-hand column shows 
a concrete example (an instance) of each of these con- 
cepts. On the Object level, the shown object is of the 
type "laserprinter" of the vendor "Hewlett-packardV On 
the Class level, the shown object is a class "printer" with 
the attributes "type" and "vendor". On the Meta level, 
the shown object is "MetaClass" which is a class of 
classes. Its (meta) attributes are "classname" (here: 
"printer") and "attributes" (here "type", "vendor"). The 
implementation of such a meta level allows the instan- 
tiation of new classes during runtime, without a change 
of the database schema. 

[0061] A preferred embodiment of a remote support- 
service method carried out with the preferred embodi- 
ments of the remote support-service system of Fig. 1 is 
illustrated in Fig. 1 4. Steps V1 to V10 are carried out by 
the IDT 1 at the customer's site, whereas steps V11 to 
V1 3 are earned out by the ISST 2 at the support-service 
provider's site. The method is earned out automatically 
and periodically as a background task, but can also be 
executed on demand by the customer or support-serv- 
ice provider. 

[0062] In step V1 , the discovery component 7 per- 
forms the discovery task. It discovers changes in the IT 
infrastructure 5, for example, the appearance of a new 
infrastructure element or the modification or disappear- 
ance of an already existing infrastructure element, in- 
cluding the inter-relation between infrastructure ele- 
ments (i. e. the infrastructure topology). In step V2, it is 
ascertained whether a change in the IT infrastructure 5 
has been discovered. If the answer is positive, the dis- 
covery component 7 informs the IDT controller 6 corre- 
spondingly. In step V3, the IDT controller 6 finds out, if 
a new infrastructure element has been discovered, what 
that element is and what data have to be collected for 
it, by consulting the collection configuration component 
11 . In steps V4 and V5, the IDT controller 6 initiates the 
mapping of the IT infrastructure into a corresponding da- 
ta model in the storage component 8, and configures 
the data collector 9 correspondingly, if the answer in 
step V2 is negative, the process does not carry out steps 
V3 to V5, but continues with step V6. In step V6, the 
collector 9 collects the data to be collected from the in- 
frastructure 5 and returns them to the IDT controller 6. 
In step V7, the IDT controller 6 inputs the collected data 
into the storage component 8. In step V8, the IDT con- 
troller 6 decides whether the data are to be transferred 
to the ISST 2. If the answer is negative, the flow returns 
to step V1 . If the answer is positive, in step V9 the IDT 
controller 6 prepares a data file to be transferred. In 
some embodiments, the data preparation step V9 in- 
cludes a consolidation of the data to be transferred, in 
step V1 0, the IDT controller 6 instructs the transport of- 



fice manager 1 0a to send the prepared file to the ISST 
2. The steps V1 to V8 are carried out in a permanent 
loop, depending on a collection schedule in step V6 (for 
example, every full hour). The decision that data are to 

5 be transferred to the ISST in step V8 can be taken de- 
pending on the result of the collection in step V6. For 
example, the data transfer may periodically be earned 
out at greater time intervals than the collection period, 
if no (or no relevant) change has been found in the dis- 

w covery and data collection, but is carried out immediate- 
ly if such a change has been detected. 
[0063] The remaining steps V11 to V1 3 are performed 
out at the support-service provider's site. In step V11 , 
the file sent from the customer's site is received. In step 

15 V1 2, the file is stored in the ISST storage component 1 4 
and analyzed by the analysis component 16. In step 
V13, actions are taken depending on the results of the 
analysis. A standard action is, for example the provision 
of a status report. If faults, malfunctions, outdated soft- 

20 ware versions etc. have been detected, the correspond- 
ing action may be the triggering of an alarm, the instruct- 
ing of service personnel, the triggering of a software up- 
date action etc. 

[0064] Fig. 1 5 illustrates an embodiment wherein the 

25 support service is provided by several co-operating sub- 
services which may be located at different sites, namely 
a service and support portal 2a, several problem-do- 
main-specific diagnostic services 2b to 2e and an overall 
support provider 2f. The customer communicates with 

30 the services and support portal 2a in order to subscribe 
to a support service. The particular service can be indi- 
vidually tailored to the particular customer's IT infra- 
structure 5 and the customer's specific needs (for ex- 
ample, his specific security requirements). 

35 [Q065] The problem-domain-specific diagnostic serv- 
ices 2b to 2e are specialized to provide support for spe- 
cific parts of the customer's IT infrastructure 5. They are, 
for example, a NT support-service tool 2b, an UNIX sup- 
port-service tool 2c, a network support-service tool 2d 

40 and generalized diagnosis support-service tool 2e. The 
customer's IDT 1 is equipped with a data distribution 
component (not shown) which knows what data are rel- 
evant for which one of the problem domains specific di- 
agnostic services 2b to 2e, and groups and addresses 

45 the data to be transferred to the corresponding one of 
the services 2b to 2e. 

[0066] In addition, the IDT 1 keeps the overall support 
provider 2f informed about any data transfer to the serv- 
ices 2a to 2e by transferring corresponding notifications 
50 to it. The results obtained by the data analysis carried 
out by the problem-domain-specific diagnostic services 
2b to 2e are transferred directly to the overall support 
provider 2f . 

[0067] The overall support provider 2f collects the re- 
55 suits from the services 2b to 2e, sends overall reports 
and alarms to the customer 1 (which are called Trouble 
Tickets 5 in Fig. 15) and provides an overall monitoring 
facility for the customer 1 and the co-operating sub-serv- 
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ices 2a to 2f via IP links. The messaging can be based 
on XML 

[0068] Fig. 16 describes steps S1 to S5 of Fig. 3 in 
detail. The collection is a two-step process. In the first 
step, a client application (i.e. the NDT controller 6) con- s 
figures a collection task and passes the task to the col- 
lector Fig. 6 shows what happens when a new collect- 
ible is inserted by the client, i.e. the procedural steps 
during insertion of a new task. 

[0069] When the client application adds a new task to 10 
the collector, the collector checks whether the collection 
task is valid. In this embodiment, validity means that the 
task has configured the following attributes: 

• A schedule; is 

• A valid collectible definition; 

• Device information that contains the IP address and 
other access parameters for the collectible; 

• A non-null session identification that defines the ap- 
plication that defined the task. 20 

[0070] If the task is not valid, it is rejected with an error 
message. The next step is to check whether the collect- 
ible definition matches the collector, e.g. that the SNMP 
collector gets only SNMP collectible definitions and not 25 
DM I collectibles. The task is rejected when the collecti- 
ble does not match the collector. In the positive case the 
collector forwards the task to its scheduler. The sched- 
uler determines the date and time of the first collection 
and inserts the task into its queue. 30 
[0071] Fig. 17 describes steps S6 to S8 of Fig. 3 in 
detail. The scheduler has an internal priority queue that 
holds a list of all collection tasks sorted by time. When 
a collection task is ready, the steps shown in the flow- 
chart depicted in Fig. 17a, which is the first part of an 35 
entire flow chart continued in Fig. 17b, are executed. It 
is noteworthy that the tasks are executed for every col- 
lection task that has to be performed. Fig. 1 7 particularly 
shows an exemplary scheduling (a) and applying strat- 
egy (b) by means of a task execution process flowchart. m 
[0072] At the beginning, the scheduler removes the 
task from the priority queue and determines the next col- 
lection time. Sometimes there will be no next collection 
time, e.g. in the case of a collect once schedule. If there 
is a collection time, the scheduler will insert the task with 45 
the new collection time again. Otherwise the task will 
not be inserted into the queue and therefore not handled 
again (i.e. collect once). 

[0073] The next step checks whether the task should 
be forwarded to a corresponding strategy. If thetaskwas so 
suspended due to repeated errors, the scheduler will 
check whether to restart the task again. If it should be 
disabled, the task is finished. Otherwise the scheduler 
will change the status of the task to 'active' and pass the 
task to the strategy. If the task was not suspended due ss 
to errors, it may be suspended at this point. Otherwise 
the task will be forwarded to the corresponding strategy. 
[0074] The strategy holds a list of all collection tasks 



that have to be performed as fast as possible and pass- 
es the tasks, in accordance with the strategy, to the re- 
spective collection method. The collection method tries 
to retrieve the collectible. If the collection succeeds, a 
retry counter is reset which is used for suspending tasks 
that resulted in several repeated errors. Further it deliv- 
ers the result and notifies it to the client if applicable. If 
the collection fails, the strategy increments the retry 
counter. The task is when the counter reaches a maxi- 
mum. 

[0075] Figs. 18 and 19 a-c show interfaces and their 
hierarchies. Fig. 18 shows interfaces for collectible def- 
initions. Common to all collectible definitions is a 'name* 
and a 'unique identifier 1 . Protocol specific information is 
provided by derived protocol specific interfaces. For in- 
stance, the interfaces MSNMPCollectibleDef define 
items that can be retrieved via SNMP. 
[0076] Referring now to Fig. 1 9a, strategies are used 
to control access to a device. The base interface 'Icol- 
lectionStrateoy consists of two methods. The method 
'Collection Method 1 sets the collection method that is 
used in conjunction with that strategy. The collection 
method is preferably part of the protocol. The interface 
'IparallelCollectionStrategy 1 is an inherited interface 
from 'IcollectionStrategy'. It has additional methods to 
set the maximum number of threads and to retrieve the 
number of currently active threads. 
[0077] Now referring to Fig. 19b, the first group of in- 
terfaces defines collection schedules. The collection 
schedules are used by the scheduler in order to find out 
when to perform a collection task. The interface basical- 
ly provides two methods. One returns the date for the 
first* collection and the second method returns the date 
of the 'next 1 collection. 

[0078] Referring to Fig. 1 9c t a family of device infor- 
mation interfaces define how to access a device. The 
base interface contains only the network address of the 
device. Protocol specific information like SNMP commu- 
nity strings, retry and timeouts are defined in protocol 
dependent interfaces. It is noted that the device infor- 
mation is protocol dependent. For example, an SNMP 
collection task needs the SNMP community strings. 
These strings are not provided by the base interface 
'IDevicelnfo'. In order to define SNMP collection tasks, 
the interface 'ISNMPDevicelnfo' is to be used. This in- 
terface is derived from the interface 'IDevicelnfo' and ex- 
tended by commonly known methods (algorithms) to re- 
trieve and set the community strings. 
[0079] Finally, Fig. 20 shows the DMI collector 22 of 
Figs. 2 and 3 and a corresponding algorithm in greater 
detail. The DMI collector retrieves arbitrary DMI groups 
and DMI tables. A DMI collectible is defined by the 
above described interface IDMICollectibleDef. A DMI 
collectible is particularly defined by the following at- 
tributes: 

• The component name; 

• The class name for the DMI group or table; 
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• A list of IDs. 

[0080] The DM I collector performs the following steps 
for each collectible: 

5 

• Enumerate all components for a device 

• For each component that matches the component 
name in the collectible definition: 

• Enumerate all DM I classes in the component; 10 

• For each class that matches the class name in 
the collectible definition: 

• Collect the item and return the result. 

15 

[0081] Thus, a general purpose of the disclosed em- 
bodiments is to provide an improved system, computer 
program product and a method for providing a remote 
support service. 

[0082] All publications and existing systems men- 20 
tioned in this specification are herein incorporated by 
reference. 

[0083] Although certain systems, methods and prod- 
ucts constructed in accordance with the teachings of the 
invention have been described herein, the scope of cov- 25 
erage of this patent is not limited thereto. On the con- 
trary, this patent covers all embodiments of the teach- 
ings of the invention fairly falling within the scope of the 
appended claims either literally or under the doctrine of 
equivalents. 30 

Claims 

1 . A system for providing a remote support service be- 35 
tween at least one support-service provider's site 
and a customer's site having a customer's informa- 
tion technological (IT) infrastructure, comprising: 

an information collecting component which col- 40 
lects information about the customer's IT infra- 
structure; 

a storage component which stores collected in- 
formation according to a data model modeling 
at least part of the customer's IT inf rastructu re; 45 
an information-transferring component capable 
of transferring at least part of the collected or 
stored information or a representation of it to 
the support-service provider; 
an analysis component which analyzes the so 
stored or transferred information or represen- 
tation as a basis for the provision of the remote 
support services. 
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3. The system of claim 1 or 2, wherein the analysis 
component is located at least at one of the custom- 
er's site and the support-service provider's site. 

4. The system of any one of claims 1 to 3, further com- 
prising a consolidator component which is capable 
of generating a consolidated representation of the 
collected or stored information, said consolidator 
component is located at least at one of the custom- 
er's site and the support-service provider's site. 

5. The system of any one of claims 1 to 4, wherein the 
customer's IT infrastructure comprises at least one 
of the following elements: network infrastructure el- 
ements, storage systems, hardware elements and 
peripherals, operating systems, networking soft- 
ware, database software, middleware and utilities, 
software applications; and wherein the information 
collecting component collects information about at 
least one of these elements and the data model 
models at least part of these elements and their in- 
ter-relations. 

6. The system of any one of claims 1 to 5, further com- 
prising a discovery component capable of automat- 
ically discovering changes in the customer's IT in- 
frastructure, and wherein the data model is auto- 
matically adapted so that it models the changed IT 
infrastructure. 

7. The system of claim 6, wherein, due to the automat- 
ic discovering capability of the discovery compo- 
nent, after an installation of a program code repre- 
senting the software parts of the information collect- 
ing component, the storage component and the in- 
formation-transferring component at the customer's 
site, the system automatically discovers at least 
part of the customer's IT infrastructure and automat- 
ically generates a data model which models it. 

8. The system of any one of claims 1 to 7, wherein, in 
the database component, the elements of the cus- 
tomer's IT infrastructure are mapped to classes, 
and wherein new classes can dynamically be add- 
ed, and wherein the classes have flexible attributes 
which can be dynamically added and changed. 

9. The system of any one of claims 1 to 8, wherein the 
information-transferring component is capable of 
transferring the collected or stored information or a 
representation of it via an information network, par- 
ticularly the Internet, to the support-service provid- 
er, or by means of a data carrier. 
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2. The system of claim 1 , wherein the storage compo- 55 
nent is located at least at one of the customer's site 
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10. The system of any one of claims 1 to 9, wherein the 
database component stores at least one of config- 
uration and performance history information of the 
customer's IT infrastructure. 
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11. The system of any one of claims 1 to 10, wherein 
the analysis component monitors or analyzes at 
least on of configuration, configuration changes, 
performance and performance changes of the cus- 
tomer's IT infrastructure. 

12. The system of any one of claims 1 to 11 , wherein 
the information collecting component comprises a 
scheduler which schedules the collection of the in- 
formation about the customer's IT infrastructure. 

13. The system of any one of claims 1 to 12, wherein 
the collection strategy or schedule is determined in- 
dividually for the customers, depending on the par- 
ticular support service contract between the cus- 
tomer and the support-service provider. 

14. A computer system forming a customer based part 
of a system for providing a remote support service 
between at least one support-service provider's site 
and the customer's site having a customer's infor- 
mation technological (IT) infrastructure, compris- 
ing: 

an information collecting component which col- 
lects information about the customer's IT infra- 
structure; 

a storage component which stores collected in- 
formation according to a data model modeling 
at least part of the customer's IT infrastructure; 
an information-transferring component capable 
of transferring at least part of the collected or 
stored information or of a consolidated repre- 
sentation of it to the support-service provider. 

15. The computer system of claim 14, having one or 
more features of any one of claims 1 to 13. 

16. A computer program product including program 
code for execution on a customer-based computer 
system which is part of a system for providing a re- 
mote support service between at least one support- 
service provider's site and the customer's site hav- 
jng a customer's information technological (IT) in- 
frastructure, said program code comprising soft- 
ware parts of: 

an information collecting component which col- 
lects information about the customer's IT infra- 
structure; 

a storage component which stores collected in- 
formation according to a data model modeling 
at least part of the customer's IT infrastructure; 
an inf ormation-transf erring component capable 
of transferring at least part of the collected or 
stored information or of a consolidated repre- 
sentation of ii to the support-service provider. 



17. The computer program product of claim 1 6, having 
one or more features of any one of claims 1 to 13. 

1 8. A method for providing a remote support service be- 
s tween at least one support-service provider's site 

and a customer's site having a customer's informa- 
tion technological (IT) infrastructure, comprising the 
steps of: 

collecting information about the customer's IT 
infrastructure; 

storing collected information according to a da- 
ta model modeling at least part of the custom- 
er's IT infrastructure; 

transferring at least part of the collected or 
stored information or a representation of it to 
the support-service provider; 
analyzing the stored or transferred information 
or representation as a basis for the provision of 
the remote support services. 

19. The method of claim 18, having one or more fea- 
tures of any one of claims 1 to 13. 
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